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I. Real Party in Interest (37 C.F.R. §1.192(c)(l)) 

The real party in interest in the present appeal is Microsoft Corporation, the 
assignee of the present application. 

II. Related Appeals and Interferences (37 C.F.R. §1. 192(c)(2)) 

Appellants, appellants' legal representative, and/or the assignee of the present 
application are not aware of any appeals or interferences which will directly affect, or be 
directly affected by or have a bearing on the Board's decision in the pending appeal. 

III. Status of Claims (37 C.F.R. §1.192(c)(3)) 

Claims 1-25 are pending in the application. The rejection of claims 1-25 is being 
appealed. 

IV. Status of Amendments (37 C.F.R. §1.192(c)(4)) 

No claim amendments have been entered after the Final Office Action. 

V. Summary of Invention (37 C.F.R. §1.192(c)(5)) 

The present invention relates to systems and methods that authenticate a service, 
and more specifically to authenticating services between a client and a server by a trusted 
third party wherein aliasing is employed to reduce management overhead associated with 
conventional systems. (See page 1, lines 5, 6). In general, a request is made by a second 
party to a first party (e.g., a trusted third party) to authenticate a service via an alias. 
Based on the request, the first party searches list of aliases associated with the service. 
(See page 4, lines 7-10). If a match is found between the first alias and at least one alias 
in the list, the second party can access the service. (See page 4, lines 10-13). In this 
manner, clients and servers are relieved of managing service names by enabling a trusted 
third party to authenticate the various service names. (See page 4, lines 18-20). 
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VI. Statement of the Issues (37 C.F.R. §1.192(c)(6)) 

A. Whether claims 1-25 are unpatentable under 35 U.S. C. §103 (a) over 
Schneier (Applied Cryptography Second Edition: protocols, algorithms and source code 
in C, 1996) and Pinkert, et ah (Operating Systems: concepts, policies and mechanisms, 
1989). 

VII. Grouping of Claims (37 C.F.R. §L192(c)(7)) 

For purposes of this appeal only, the claims are grouped as follows: 
Claims 1-25 stand or fall together. 

VIII. Argument (37 C.F.R. §1.192(c)(8)) 

A. Rejection of Claims 1-25 Under 35 U.S.C. 8103(a) 

Claims 1-25 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Schneier (Applied Cryptography Second Edition: protocols, algorithms and source 
code in C, 1996) and Pinkert, et ah (Operating Systems: concepts, policies and 
mechanisms, 1989). Reversal of this rejection is respectfully requested for at least the 
following reasons. 

L Schneier and Pinkert, et ah individually and in combination, do 
not teach or suggest the subject invention as recited in claims i, 
9-11 and 16 

To reject claims in an application under §103, an examiner must 
establish a prima facie case of obviousness. A prima facie case of 
obviousness is established by a showing of three basic criteria. 
First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one 
of ordinary skill in the art, to modify the reference or to combine 
reference teachings. Second, there must be a reasonable expectation 
of success. Finally, the prior art reference (or references when 
combined) must teach or suggest all the claim limitations. See 
MPEP §706.02(j). The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be 
found in the prior art and not based on applicant's disclosure. See In 
re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). 
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Independent claim 1 (and similarly independent claims 9-1 1 and 16) recites a 
method to authenticate a service by making a request to a first party utilizing a first 
alias and searching a list of aliases associated with the service... then allowing a second 
party making the request to access the service if a match is found between the first alias 
and at least one alias in the list of aliases. 

Schneier does not teach or suggest authentication of a service to a second party 
{e.g., client), as recited in the subject claims. In accordance with this feature of the 
claimed invention, the second party can insure that the service they wish to access is 
authentic to the system and that "unscrupulous users are prevented from diverting 
confidential client information." {See page 5, lines 20-22). Schneier does not teach such 
claimed aspects of the subject invention. Instead, Schneier teaches authentication of a 
client that wishes to access a particular service. For instance, as disclosed in Schneier, 
the client requests a ticket for a ticket granting service, the ticket is encrypted, and the 
encrypted ticket is presented to a server to gain access to a desired service. Such 
authentication is employed to insure that "nothing is wrong with the client's credentials." 
{See Schneier, page 567). Thus, Schneier is concerned with authentication of the client 
and not authentication of a service, as recited in the subject claims and thus does not 
teach or suggest all limitations of the subject claims. 

In support for the Examiner's contention that Schneier teaches the aforementioned 
features of applicants 5 claimed invention, he asserts that Schneier, at p.567 discloses 
"wherein the search results for the search match results for the key words are. . .in which a 
search match for a first number of the one or more search engines displayed. . ." As 
previously noted in the Reply to the Office Action dated September 23, 2003, the Reply 
to Final Office Action dated February 23, 2004 and again in the Reply to Advisory 
Action dated May 11, 2004, this language is not mentioned on the page cited by the 
Examiner. Instead, this passage is directed to authentication of a client and how a client 
may communicate with a server utilizing Kerberos. Moreover, such language or the like 
is not found elsewhere in the reference. Regardless of the presence or absence of such 
language, Schneier does not teach authentication of a service as in applicants' claimed 
invention. 

The Office Action relies on Pinkert et al. to teach or suggest various aspects of the 
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claimed subject invention. However, in view of the aforementioned deficiencies of Schneier 
and sincePinkert et al does not make us for such deficiencies, the purported combination of 
these references would not result in applicants' claimed invention because neither reference 
teaches or suggests authenticating a service as recited in the subject claims. 

iL The cited references, Schneier and Pinkert, et al, do not provide 
proper motivation to be combined in the manner suggested in the 
Office Action dated February 23, 2004. 

Notwithstanding that the cited references do not make obvious the claimed invention, 
there is no motivation or suggestion to combine the references in the manner suggested. In 
order to reject claims in an application pursuant to 35 U.S.C. §103, there must be some 
logical reason apparent from positive, concrete evidence of record, which justifies a 
combination of primary and secondary references. See In re Lakowski 871 F.2d 115; 10 
U.S.P.Q.2D (BNA) 1397 (Fed. Cir. 1989) citing In re Kegel, 526 F.2d 1399, 1403 n.6, 188 
USPQ 136, 140 n.6 (CCPA 1975). A challenger to the validity of a patent cannot pick and 
choose among the individual elements of assorted prior art references to recreate the claimed 
invention; the challenger has the burden to show some teaching or suggestion in the 
references to support their use in the particular claimed combination. See Smithkline 
Diagnostics, Inc. v. Helena Laboratories Corp., 859 F.2d 878, 887, 8 USPQ2d 1468, 1475 
(Fed. Cir. 1988). 

The Examiner contends that motivation to combine the cited references exists by 
"allowing users to reference the same physical file by different logical names." (See Pinkert, 
et al, p. 205, Tf8). However, merely providing a definition of an alias from Pinkert, et al 
does not provide the necessary motivation to combine such reference with Schneier. Pinkert 
et al is non-analogous art to the claimed invention. In general, Pinkert et al is directed to 
operating systems and corresponding file names - the aliasing taught by Pinkert et al is 
directed to techniques for naming and organizing files in an operating system and is not 
related to service authentication as recited in the subject claims. There is no evidence that 
one skilled in the art of service authentication logically would look to the art of file naming 
(e.g., aliasing) taught by Pinkert, et al 
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Moreover, nowhere does Pinkert, et al. mention the use of aliasing in conjunction 
with the third party authentication protocol disclosed in Schneier. Similarly, there is no 
mention in Schneier of utilizing aliasing with a third party trusted authentication system, 
as recited in the subject claims. It is readily apparent that the Examiner has not met the 
requisite burden to show proper motivation to combine Pinkert et al with Schneier. The 
prior art items themselves must suggest the desirability and thus the obviousness of 
making the combination without the slightest recourse to the teachings of the patent or 
application. Without such independent suggestion, the prior art is to be considered 
merely to be inviting unguided and speculative experimentation, which is not the 
standard with which obviousness is determined. Amgen, Inc. v. Chugai Pharmaceutical 
Co. Ltd., 927 F.2d 1200, 18 USPQ2d 1016 (Fed. Cir. 1991); In reLaskowski, 871 F.2d 
115, 117, 10 USPQ2d 1397, 1398 (Fed. Cir. 1989); In re Dow Chemical Co., 837 F.2d 
469, 473, 5 USPQ2d 1529, 1532 (Fed. Cir. 1988); Hodosh v. Block Drug, 786 F2f at 
1 143 n. 5., 229 USPQ at 187 n. 4.; In re Gordon, 733 F.2d 900, 902, 221 USPQ 1 125, 
1127 (Fed. Cir. 1985). 

Additionally, the statement by the Examiner that such a modification would allow 
"users to reference the same physical file by different logical names" is an inadequate 
rationale for effecting the purported combination. Even though it is possible to try 
combinations of elements to recreate the subject invention, trying to combine references 
does not meet the standard pursuant to 35 U.S.C. §103 of nonobviousness. Stating that 
such a modification would be obvious to try to modify Schneier to teach the subject 
invention is inadequate to establish a prima facie case of nonobviousness. "Obvious to 
try" is not the standard of 35 U.S.C. §103. A disregard for unobviousness of results of 
"obvious to try" experiments disregards the "invention as a whole" concept of Section 
103. In re Goodwin, 576 F.2d 375, 198 USPQ 1 (CCPA 1978). The standard of 35 
U.S.C. §103 is not that it could be obvious for one skilled in the art to try. In re Antonie, 
559 F.2d 618, 195 USPQ2d 6 (CCPA 1977). There is usually an element of obviousness 
to try in any research endeavor. . .[patentability based on that as a test would be contrary 
to the statute. In re Tomlinson, 363 F.2d 928, 150 USPQ 623 (CCPA 1966). 

It appears the Examiner is impermissibly employing 20/20 hindsight with 
applicants' specification as a roadmap to make the purported combination. The rationale 
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proffered to modify and combine Schneier and Pinkert et al is to achieve benefits 
identified in applicants' specification, which overcome problems associated with 
conventional systems and/or methods. Applicants' representative respectfully submits 
that this is an unacceptable and improper basis for a rejection under 35 U.S.C. §103. In 
essence, the Examiner is basing the rejection on the assertion that it would have been 
obvious to do something not suggested in the art because so doing would provide 
advantages stated in applicants' specification. This sort of rationale has been condemned 
by the Court of Appeals for the Federal Circuit. See, for example, Panduit Corp. v. 
Dennison Manufacturing Co., 1 USPQ2d 1593 (Fed. Cir. 1987). 

In the Final Office Action, the Examiner states that "as long as [the reference] 
takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only 
from the applicant's disclosure, such a reconstruction is proper." However, there is no 
evidence that utilizing aliasing in relation to service authentication can be gleaned from 
either reference cited by the Examiner. Rather, the basis for combining the references 
appears to be premised solely on what is taught by applicants' specification. 

The alleged motivation to combine Schneier with Pinkert, et al is merely that 
Pinkert et al teaches the definition of aliasing - this is not enough. Pinkert et al is 
limited to naming and organization of files and, as noted supra, no positive and concrete 
basis has been provided for combining Pinkert et al with Schneier absent employment of 
the teachings of applicants' specification. Thus, the Examiner has not met his burden to 
show proper motivation to combine the references. 

In view of at least the foregoing, it is readily apparent that there is no suggestion 
or motivation to combine Schneier and Pinkert et al, and even as combined in the 
manner suggested do not make obvious the subject invention as recited in independent 
claims 1,9-11 and 16 (and claims 2-8, 12-15 and 17-25 which respectively depend there 
from). Accordingly, this rejection should be withdrawn. 



7 



09/560,079 



MS 1 39778 .02/MSFTP 1 1 3US A 



IX. Conclusion 

For at least the above reasons, the claims currently under consideration are 
believed to be patentable over the cited references. Accordingly, it is respectfully 
requested that the rejections of claims 1-25 be reversed. 

If any additional fees are due in connection with this document, the 
Commissioner is authorized to charge those fees to Deposit Account No. 50-1063. 



AM IN & TUROCY, LLP 

24 th Floor, National City Center 
1900 East 9 th Street 
Telephone: (216)696-8730 
Facsimile: (216)696-8731 



Respectfully submitted, 

AMIN & TUROCY, LLP 




Himanshu S. Amin 
Reg. No. 40,894 



8 



09/560,079 



MS139778.02/MSFTP113USA 



X. Appendix of Claims (37 C.F.R. §1.192(c)(9)) 

1 . A method for facilitating authentication of a service, comprising the steps 

of: 

making a request to a first party for authentication of the service, the request 
including a first alias; 

searching a list of aliases associated with the service; 

enabling a second party making the request to access the service if a match is 
found between the first alias and at least one alias of the list of aliases. 

2. The method of claim 1 wherein the first party is a domain controller. 

3. The method of claim 2 wherein the domain controller includes a directory 
service and a Global Catalog Service. 

4. The method of claim 1 wherein the authentication of the service is 
provided via Kerberos. 

5. The method of claim 1 wherein the aliases are Service Principal Names. 

6. The method of claim 5 wherein the Service Principal Names further 
comprise at least one of a Service Type, an Instance Name, a Port Number, a Service 
Name and a Domain. 

7. The method of claim 5 wherein the Service Principal Names are 
associated with an account related to a server. 
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8. The method of claim 7 wherein the step of searching a list of aliases 
further comprises the steps of: 

searching the account for an associated Service Principal name; and 

providing name cannonicalization by returning a ticket related to the account. 

9. A domain controller for facilitating a client authenticating a server, 
comprising: 

a system for providing a plurality of aliases which the client may employ to 
authenticate to the server. 

10. A system for facilitating a client authenticating a server, comprising: 
a domain controller operatively coupled to the client and server, the domain 

controller providing a plurality of aliases which permit the client to authenticate the 
server via at least one of the aliases. 

11. A system for facilitating authentication of a service, comprising: 
means for receiving a request for authentication of the service from a client, the 

request including a first alias; 

means for searching a list of aliases associated with the service; 

means for enabling the client to access the service if a match is found between the 
first alias and at least one alias of the list of aliases. 

12. The system of claim 1 1 further including a means for generating an 
implicit list facilitating automatic creation of Service Principal Names. 

13. The system of claim 12 further including a means for constraint checking 
in order to prevent authentication to an unauthorized server. 
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14. The system of claim 13 wherein the means for constraint checking 
includes a Host Name and an attribute. 

15. The system of claim 14 wherein the means for constraint checking 
includes having a means for determining if a server is authentic by matching the Host 
Name with the attribute. 

16. A system for facilitating authentication of a service, comprising: 

a domain controller for receiving a request for authentication of the service from a 
client, the request including a first alias; 

wherein the domain controller searches a list of aliases in an account associated 
with the service; 

wherein the domain controller enables the client to access the service via a ticket 
if a match is found in the account between the first alias and at least one alias of the list of 
aliases. 

17. The system of claim 16 wherein the aliases are Service Principal Names. 

18. The system of claim 17 wherein the Service Principal Names further 
comprise at least one of a Service Type, an Instance Name, a Port Number, a Service 
Name and a Domain. 

19. The system of claim 16 further including an implicit list to facilitate 
automatic creation of Service Principal Names. 

20. The system of claim 19 further including constraint checking in order to 
prevent authentication to an unauthorized server. 
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2 1 . The system of claim 20 wherein the constraint checking includes a Host 
Name and an attribute. 

22. The system of claim 21 wherein the constraint checking includes 
determining if a server is authentic by matching the Host Name with the attribute. 

23. The system of claim 16 further including a referral service for directing 
the client to another domain. 

24. The system of claim 23 wherein the domain the client is directed to may 
refer the client to another domain. 

25. The system of claim 16 wherein improved security is provided for 
replicated services by including the name of the replicated service within a Service 
Principal Name. 
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